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Abstract 


This document proposes an experimental set of alternative decision- 
making processes for use in IETF working groups. There are a small 
number of cases in IETF working groups in which the group has come to 
consensus that a particular decision must be made but cannot agree on 
the decision itself. This document describes alternative mechanisms 
for reaching a decision in those cases. This is not meant to provide 
an exhaustive list, but to provide a known set of tools that can be 
used when needed. 


1. Introduction 


Dave Clark’s much-quoted credo for the IETF describes "rough 
consensus and running code" as the key criteria for decision making 
in the IETF. Aside from a pleasing alliteration, these two 
touchstones provide a concise summary of the ideals that guide the 
IETF’s decision making. The first implies an open process in which 
any technical opinion will be heard and any participant’s concerns 
addressed; the second implies a recognition that any decision must be 
grounded in solid engineering and the known characteristics of the 
network and its uses. The aim of the IETF is to make the best 
possible engineering choices and protocol standards for the Internet 
as a whole, and these two principles guide it in making its choices 
and standards. 


In a small number of cases, working groups within the IETF cannot 


reach consensus on a technical decision that must be made in order to 
ensure that an interoperable mechanism or set of standards is 
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available in some sphere. In most of these cases, there are two or 
more competing proposals at approximately the same level of technical 
maturity, deployment, and specification. In some cases, working 


groups can achieve consensus to advance multiple proposals and either 
to revisit the question with experience or to build the required 
mechanisms to handle multiple options for the life of the protocol. 
In other cases, however, a working group decides that it must advance 
a single proposal. 


Choosing among proposals can be difficult especially when each is 
optimized for slightly different use cases, as this implies that the 
working group’s best choice depends on the participants’ views of 
likely future use. Further problems arise when different proposals 
assign costs in implementation, deployment, or use to different 
groups, as it is a normal human reaction to seek to prevent one’s own 
ox from being gored. 


This document proposes a set of experimental mechanisms for use in 
such cases. To gauge the results of the use of these mechanisms, the 
Last Call issued to the IETF community should note such a mechanism 
is being used and which proposal among the set was chosen. If and 
when the community becomes satisfied that one or more of these 
methods is useful, it should be documented in a BCP. 


In no way should this experiment or any future BCP for this small 
number of cases take precedence over the IETF’s normal mode of 
operation. 


2. Rough Consensus as a baseline approach 


The Conflict Research Consortium at the University of Colorado 
outlines the pros and cons of consensus as follows: 


The advantage of consensus processes is that the resulting 
decision is one that meets the interests of all the parties and 
that everyone can support. The disadvantage is that developing 
such a decision can be a very slow process, involving many people 
over a long period of time. There is also a relatively high 
probability of failure. If a quick decision is needed, the 
consensus approach may not work. Consensus rule processes also 
tend to favor those that oppose change and want to preserve the 
status quo. All these people have to do is refuse to support any 
consensus compromises and they will win (at least as long as they 
can delay change) [CONFLICT]. 
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Using "rough consensus" as a guideline limits some of the 
disadvantages of consensus processes by ensuring that individuals or 
small factions cannot easily block a decision that otherwise has 
general support. The touchstone of "running code" can also limit the 
disadvantages of consensus processes by requiring that statements 
opposing particular proposals be technically grounded. 


These limitations do not change the core mechanisms of consensus- 
building, however, and the IETF process continues to require 
individual participants both to use their best engineering judgment 
to select among proposals and to balance their own interests with 
those of the Internet as a whole. Active participation anda 
willingness to compromise, possibly on key points, are needed. 
Historically, this has worked because a large majority of 
participants have recognized that the Internet’s growth and 
enhancement are more important overall than any specific short-term 
advantage. 


In other words, "rough consensus" is sufficient in most cases in the 
IETF to ensure not only that individuals or small groups are heard 
when they raise technical objections, but also that they cannot block 
progress when general agreement has been reached. This document does 
not suggest changing the usual mechanisms for achieving progress; it 
proposes mechanisms for use when a working group has consensus that 
it must make a decision but cannot make that decision by the usual 
rules. 


3. Conditions for use 


In general, working groups should consider using alternate decision- 
making processes when it is clear both that a choice must be made and 
that the choice cannot be made with continued discussion, refinement 
of specifications, and implementation experience. A guideline for 
determining whether these conditions have been met is included below. 


3.1. There is a clear decision to be reached 


There must be a clear statement of the decision to be reached. This 
may be in the working group’s charter, in requirements documents, or 
in other documents developed by the working group. Prior to any 
invocation of an alternate decision making process, the Chair(s) 
should confirm with the working group that there is general agreement 
on the decision to be reached. This should include a specific 
consensus call on whether the working group can advance multiple 
proposals or must select a single proposal for the work item. 
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3.2. Proposals are available in Draft form 


Proposed solutions must be available as Internet-Drafts and must be 
sufficiently specified so that the Chair(s) believe they could be 
published as an IETF specification, possibly with further refinement. 
If the Chair indicates that a proposed solution is insufficiently 
specified, concrete problems must be identified, and a reasonable 
amount of time provided to resolve those problems must be provided. 
Note that if one of the proposed solutions is "do nothing", an 
explicit Draft to that effect must be available; it may, however, be 
produced when the group invokes an alternate decision-making process. 


3.3. The working group has discussed the issue without reaching 
resolution 


Consensus-—building requires significant amounts of discussion, and 
there is no general rule for indicating how much discussion a 
technical issue requires before a group should reach consensus. If 
there is any question about whether the discussion has been 
sufficient, the working group chair(s) should always err on the side 
of allowing discussion to continue. Before using an alternate 
decision making process, the working group chair(s) should also make 
an explicit call for consensus, summarizing the technical issues and 
the choice to be made. If new technical points are made during the 
call for consensus, discussion should continue. If no new points are 
raised, but the group cannot come to consensus, the working group may 
consider using an alternate decision making process. Under no 
circumstances is the working group required to use an alternate 
decision-making process. 


3.4. There is an explicit working group last call to use an alternate 
method 


In item 3.3 above, it is noted that the Chair(s) should make an 
explicit call for consensus on the technical issues and should 
proceed only after that call has yielded no forward progress. A 
different Last Call on whether to use an alternate decision-making 
method is required, with a stated period for comments by working 
group members. This is to indicate that the decision to use an 
alternate method should be taken at least as seriously as the 
decision to advance a document on the standards track. It also 
provides a clear signal that this is a last moment for participants 
to reconsider their positions. The decision to use an alternate 
decision making process requires the rough consensus of the working 
group, as determined by the Chair(s). The choice of which process to 
use may be made in the Last Call or may be the subject of separate 
discussions within the working group. If the group comes to 
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consensus that an alternative method is required but does not come to 
consensus on the method to use, an external review team (c.f. section 
4.1, below) will be formed. 


In discussions regarding this document, several points have been 
raised about the viability of any mechanism that requires consensus 
to use an alternative to consensus-based decision making. Some 
individuals have pointed out that groups having trouble achieving 
consensus on a technical matter may have similar problems achieving 
consensus on a procedural matter. Others have been concerned that 
this will be used as an attempt to end-run around rough consensus. 
These are valid concerns, and they point both to the need to retain 
rough consensus as the baseline mechanism and the need to exercise 
caution when using these alternate methods. More importantly though, 
they highlight the nature of these alternatives. They are primarily 
mechanisms that allow people to recognize the need for compromise in 
a new way, by backing away from entrenched technical positions and by 
putting the technical choice in the hands of the broader community. 
They highlight that the choice for each participant is now between 
achieving a result and failure. 


There is a fundamental tension between the IETF community’s desire to 
get the best decision for a particular technical problem and its 
desire to get a decision that has community buy-in in the form of 
rough consensus. These mechanisms cannot resolve that fundamental 
tension. They may, however, provide a way forward in some situations 
that might otherwise end in a deadlock or stagnation. 


4. Alternate Methods 


In setting up an alternate method, care must be taken that the 
process by which the decision is reached remains open and focused on 
the best technical choice for the Internet as a whole. The steps set 
out below provide a straw proposal for four such mechanisms. These 
systems are relatively heavyweight, partially to highlight the 
gravity of invoking these methods and partially to ensure that the 
IETF community as a whole is alerted to and kept informed of the 
process. Note that alternate procedures have been used in the past; 
see [RFC3127] for a description of that used in the decision between 
two competing candidate protocols for Authentication, Authorization, 
and Accounting. By setting out these proposals, this document does 
not intend to limit working group choice but intends to provide a set 
of well-defined processes that obviate the need for reinvention in 
most cases. 
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4.1. Alternate Method One: External Review Team Formation 


The working group notifies the IETF community that it intends to form 
an external review team by making a public announcement on the IETF- 


announce mailing list. That announcement should include a summary of 
the issue to be decided and a list of the Internet-Drafts containing 
the alternate proposals. It should also include the name and 
location of an archived mailing list for the external review team’s 
deliberations. 

4.1.1. External Review Team Membership 


External review teams have five members who must meet the same 
eligibility requirements as those set out for a voting member of the 
NomCom [RFC3777]. Explicitly excluded from participation in external 
review teams are all those who have contributed to the relevant 
working group mailing list within the previous twelve months, the 
IESG, the IAB, and the members of an active NomCom. 


Volunteers to serve on the review team send their names to the IETF 
executive director. Should more than five volunteer, five are 
selected according to the process outlined in [RFC3797]. Note that 
the same rules on affiliation apply here as to the NomCom, to reduce 
the burden on any one organization and to remove any implication of 
"packing" the review team. 


Participants in the working group may actively solicit others to 
volunteer to serve on the review team but, as noted above, they may 
not serve themselves if they have commented on the list within the 
previous twelve months. 


4.1.2. External Review Team Deliberation 


The external review team is alloted one month for deliberations. Any 
member of the team may extend this allotment by two weeks by 
notifying the relevant working group Chair(s) that the extension will 
be required. 


The team commits to reading the summary provided during the IETF 
announcement and all of the relevant Internet-Drafts. Members may 
also read the archived mailing list of the working group and may 
solicit clarifications from the document authors, the working group 
chairs, or any other technical experts they choose. All such 
solicitations and all deliberations among the review team of the 
proposals should take place on the archived mailing list mentioned in 
the IETF announcement. The team members may, of course, have one- 
on-one discussions with relevant individuals by phone, email, or in 
person, but group deliberations should be on the archived list. 
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4.1.3. Decision Statements 


Each member of the external review team writes a short decision 
statement, limited to one page. That decision statement contains a 
list of the proposals in preference order. It may also contain a 
summary of the review team member’s analysis of the problem and 
proposed solutions, but this is not required. These decision 
statements are sent to the archived mailing list, the relevant 
working group chair(s), and the IESG. 


4.1.4. Decision Statement Processing 


The decision statements will be tallied according to "instant-runoff 
voting" rules, also known as "preference voting" rules [VOTE]. 


4.2. Alternate Method Two: Mixed Review Team 


This mechanism allows the working group to designate a review team 
that involves those outside the working group and those who have been 
involved in the process within the working group. Although it may 
appear that having a single representative of each proposal will have 
a null effect on the outcome, this is unlikely, except when there is 
a binary choice, because of the rules for decision-statement 
processing (c.f. 4.1.4.). As in 4.1, the working group notifies the 
IETF community that it intends to form a mixed review team by making 
a public announcement on the IETF-announce mailing list. That 
announcement should include a summary of the issue to be decided and 
a list of the Internet-Drafts containing the alternate proposals. It 
should also include the name and location of an archived mailing list 
for the external review team’s deliberations. 


4.2.1. Mixed Review Team Membership 


Mixed review teams are composed of one designated representative of 
each of the proposals, typically the Internet-—Draft’s principal 
author, and six external members. Five of the external members are 
selected per 4.1.1. above. The sixth is designated by the IESG as a 
chair of the group. Though the primary role of the chair is to 
ensure that the process is followed, she or he may vote and engage in 
the deliberations. 


4.2.2. Mixed Review Team Deliberation 
The review team is alloted one month for its deliberations, and any 


member of the team may extend that allotment by two weeks by 
notifying the review team Chair this the extension will be required. 
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The review team commits to reading the summary provided during the 
IETF announcement and all of the relevant Internet-Drafts. Members 
may also read the archived mailing list of the working group, and of 
any other technical experts as they see fit. All such solicitations 
and all deliberations among the review team of the proposals should 
take place on the archived mailing list mentioned in the IETF 
announcement. 


4.2.3. Decision Statements 
As in 4.1.3, above. 
4.2.4. Decision Statement Processing 
As in 4.1.4, above. 
4.3. Alternate Method Three: Qualified Short-Straw Selection 


As in 4.1 and 4.2, the working group notifies the IETF community that 
it plans to use an alternate decision mechanism by making a public 
announcement on the IETF-announce mailing list. That announcement 
should include a summary of the issue to be decided and a list of the 
Internet-Drafts containing the alternate proposals. 


In this method, a single working group participant is selected to 
make the decision. Any individual who has contributed to the working 
group in the twelve months prior to the working group Last Call on 
the technical question (c.f. 3.3, above) may volunteer to serve as 
the decision maker. Individuals may qualify as participants by 
having made a public statement on the working group mailing list, by 
serving as an author for an Internet-Draft under consideration by the 
working group, or by making a minuted comment in a public meeting of 
the working group. The Chair(s) may not volunteer. Each qualified 
volunteer sends her or his name to the working group chair and the 
IETF Executive Director within three weeks of the announcement sent 
to the IETF-announce mailing list. The IETF Executive Director then 
uses the selection procedures described in [RFC3797] to select a 
single volunteer from the list. That volunteer decides the issue by 
naming the Internet-Draft containing the selected proposal in an 
email to the relevant working group chair, the working mailing list, 
and the IESG. 


4.4. Alternate Method Four: Random Assignment 


Among the small number of cases for which consensus is not an 

appropriate method of decision-making are an even smaller number for 
which the decision involves no technical points at all and a need to 
select among options randomly. The IDN working group, as an example, 
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needed to designate a specific DNS prefix. As the decision involved 
early access to a scarce resource, a random selection was required. 
In such cases, a working group may ask IANA to make a random 
assignment from among a set of clearly delineated values. Under such 
circumstances, IANA will be guided by [RFC3797] in its selection 
procedures. Under extraordinary circumstances, the working group 
may, with the approval of the IESG, ask IANA to select among a pool 
of Internet-Drafts in this way. 


5. Appeals 


The technical decisions made by these processes may be appealed 
according to the same rules as any other working group decision, with 
the explicit caveat that the working group’s consensus to use an 
alternate method stands in for the working group’s consensus on the 
technical issue. 


6. Security Considerations 


The risk in moving to a system such as this is that it shifts the 
basis of decision making within the IETF. In providing these 
mechanisms, it is hoped that certain decisions that may be 
intractable under consensus rules may be reached under the rules set 
out here. The risk, of course, is that forcing the evaluation to 
occur under these rules may allow individuals to game the system. 


7. IANA Considerations 


Section 4.3 may require the IANA to make random selections among a 
known set of alternates. 
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